最近更新了Android Studio 3.0 Stable版本，发现Support 26.+版本默认依赖了Android Architecture Components中的Lifecycle，接下来主要对Lifecycle这个组件进行简单的介绍以及自己对于该组件实现的一些分析，话不多少直接进入正题。
使用
介绍
在说使用之前，先简单解释一下这个组件的作用，从它的名字上基本就能大概的了解到，这个组件是为了监听比如我们的Activity或者Fragment的生命周期的，可以让我们在开发中很容易给ViewModel(MVVM模式)或者Presenter(MVP模式)增加生命周期，接下来开始讲它简单的用法。
开始
首先我们的Activity或者Fragment要实现LifecycleOwner接口，也就是说具有生命周期的组件来实现这个接口
/**
* A class that has an Android lifecycle. These events can be used by custom components to
* handle lifecycle changes without implementing any code inside the Activity or the Fragment.
*
* @see Lifecycle
*/
public interface LifecycleOwner {
/**
* Returns the Lifecycle of the provider.
*
* @return The lifecycle of the provider.
*/
Lifecycle getLifecycle();
}
可以看到，这个接口返回了一个Lifecycle对象，也就是生命周期的提供者，当然这里我们不用自己去实现，Support包中的Activity和Fragment中已经帮我们实现了这个接口，后面的实现分析会详细的说明Support包中具体是如何实现的。
所以就可以在我们的Activity或者Fragment中直接getLifecycle()来获得我们的Lifecycle对象了，Lifecycle是一个抽象类，里面有三个抽象方法
/**
* Adds a LifecycleObserver that will be notified when the LifecycleOwner changes
* state.
* <p>
* The given observer will be brought to the current state of the LifecycleOwner.
* For example, if the LifecycleOwner is in {@link State#STARTED} state, the given observer
* will receive {@link Event#ON_CREATE}, {@link Event#ON_START} events.
*
* @param observer The observer to notify.
*/
@MainThread
public abstract void addObserver(LifecycleObserver observer);
/**
* Removes the given observer from the observers list.
* <p>
* If this method is called while a state change is being dispatched,
* <ul>
* <li>If the given observer has not yet received that event, it will not receive it.
* <li>If the given observer has more than 1 method that observes the currently dispatched
* event and at least one of them received the event, all of them will receive the event and
* the removal will happen afterwards.
* </ul>
*
* @param observer The observer to be removed.
*/
@MainThread
public abstract void removeObserver(LifecycleObserver observer);
/**
* Returns the current state of the Lifecycle.
*
* @return The current state of the Lifecycle.
*/
@MainThread
public abstract State getCurrentState();
可以看到这三个抽象方法都是运行在主线程中的，上面的注释很清楚，这里就不做过多解释了。所以我们可以调用addObserver(LifecycleObserver)方法来增加观察者，也就是我们需要监听生命周期的类，比如ViewModel和Presenter。但是我们发现这个方法需要的参数是一个LifecycleObserver对象，所以需要给我们的ViewModel或者Presenter类增加实现这个接口，下面是LifecycleObserver类
/**
* Marks a class as a LifecycleObserver. It does not have any methods, instead, relies on
* {@link OnLifecycleEvent} annotated methods.
* <p>
* @see Lifecycle Lifecycle - for samples and usage patterns.
*/
@SuppressWarnings("WeakerAccess")
public interface LifecycleObserver {
}
可以看到这个接口没有需要实现的方法，它仅仅是起到标记的作用，说到这里，我们对于生命周期监听的准备工作就已经做完了，接下来就可以开始监听我们需要的生命周期了，比如我们需要监听onStart，那么我们可以这样定义我们的类
public class ViewModel implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START) public void onStart(){
Log.e("wcwcwc", "onStart");
}
}
这样就可以在我们的ViewModel类中监听到onStart事件了。
小结
在这里简单做一个小结
- 首先我们的
Activity或者Fragment继承Support中的Activity和Fragment（当然你也可以自己实现，那么就需要看后面的实现分析了） - 然后创建我们的观察者类，也就是实现
LifecycleObserver接口的类，比如上面的ViewModel类 - 关联，调用
Activity或者Fragment中的getLifecycle()方法得到Lifecycle对象，然后调用addObserver方法，也就是getLifecycle().addObserver(new ViewModel())，这里的ViewModel就是上面的示例类，需要注意的是，我们要记得在适当的时候调用removeObserver(LifecycleObserver)方法来移除我们的观察者，从而避免内存溢出 - 接下来就可以监听我们需要的生命周期方法了，比如上面的
onStart方法（这个方法名随意，只需要添加OnLifecycleEvent注解既可）
当然，上面的onStart方法中也可以有一个参数就像这样
public class ViewModel implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START) public void onStart(LifecycleOwner owner){
Log.e("wcwcwc", "onStart");
}
}
还记得开始我说过，要给具有生命周期的组件实现LifecycleOwner接口么，不难猜出，这个owner就是我们当前监听生命周期的Activity或者Fragment的引用。当然如果我们需要监听所有的生命周期方法，我们不需要对每一个周期对应写一个方法，只需要做一个全局的监听既可
public class ViewModel implements LifecycleObserver{
@OnLifecycleEvent(Lifecycle.Event.ON_START) public void onStart(LifecycleOwner owner){
Log.e("wcwcwc", "onStart");
}
@OnLifecycleEvent(Lifecycle.Event.ON_ANY) public void any(LifecycleOwner owner, Lifecycle.Event event){
Log.e("wcwcwc", "any >>> " + event);
}
}
看到上面的any方法，可以通过判断event参数来判断当前的生命周期，这里需要注意，比如生命周期回调onStart时，上面的打印日志如下
10-28 09:56:36.123 7311-7311/xxx E/wcwcwc: onStart
10-28 09:56:36.123 7311-7311/xxx E/wcwcwc: any >>> ON_START
可以看出，我们单独监听的生命周期会在Event.ON_ANY的前面执行。
Lifecycle组件为我们提供了如下生命周期事件
/**
* Constant for onCreate event of the {@link LifecycleOwner}.
*/
ON_CREATE,
/**
* Constant for onStart event of the {@link LifecycleOwner}.
*/
ON_START,
/**
* Constant for onResume event of the {@link LifecycleOwner}.
*/
ON_RESUME,
/**
* Constant for onPause event of the {@link LifecycleOwner}.
*/
ON_PAUSE,
/**
* Constant for onStop event of the {@link LifecycleOwner}.
*/
ON_STOP,
/**
* Constant for onDestroy event of the {@link LifecycleOwner}.
*/
ON_DESTROY,
/**
* An {@link Event Event} constant that can be used to match all events.
*/
ON_ANY
这些事件的触发是根据Lifecycle的状态触发的，在下面的分析中会着重说明。
分析
接下来我们从获取Lifecycle对象开始，分析这个组件是如何实现的。
首先我们找到Support中的Activity或Fragment，发现类实现了LifecycleOwner接口，如下
...
LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
@Override
public Lifecycle getLifecycle() {
return mLifecycleRegistry;
}
...
只提取主要部分，看到了getLifecycle方法返回了一个LifecycleRegistry对象，按照上面讲的调用顺序，获取Lifecycle引用后，要调用它的addObserver方法来添加观察者，所以我们看下LifecycleRegistry这个类对于这个方法的实现
@Override
public void addObserver(LifecycleObserver observer) {
State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
if (previous != null) {
return;
}
boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
State targetState = calculateTargetState(observer);
mAddingObserverCounter++;
while ((statefulObserver.mState.compareTo(targetState) < 0
&& mObserverMap.contains(observer))) {
pushParentState(statefulObserver.mState);
statefulObserver.dispatchEvent(mLifecycleOwner, upEvent(statefulObserver.mState));
popParentState();
// mState / subling may have been changed recalculate
targetState = calculateTargetState(observer);
}
if (!isReentrance) {
// we do sync only on the top level.
sync();
}
mAddingObserverCounter--;
}
简单分析下这个方法，重点看下4，5两行，这里创建了一个ObserverWithState类，这个类中保存着初始化状态和我们的LifecycleObserver引用（也就是用法中的ViewModel类），创建完成后，会把ObserverWithState的引用保存在一个Map中，这里避免了相同观察者的重复添加。
然后看一下ObserverWithState类
static class ObserverWithState {
State mState;
GenericLifecycleObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState) {
mLifecycleObserver = Lifecycling.getCallback(observer);
mState = initialState;
}
void dispatchEvent(LifecycleOwner owner, Event event) {
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
}
}
这个类很简单，一个构造方法，一个实例方法，从名字上可以猜到这个dispatchEvent方法就是进行事件调度的，这里我们先重点看下构造方法中的第一行，也就是将我们的传递的LifecycleObserver对象通过Lifecycling.getCallback方法转化成了GenericLifecycleObserver的引用，下来看下GenericLifeObserver类
/**
* Internal class that can receive any lifecycle change and dispatch it to the receiver.
* @hide
*/
@SuppressWarnings({"WeakerAccess", "unused"})
public interface GenericLifecycleObserver extends LifecycleObserver {
/**
* Called when a state transition event happens.
*
* @param source The source of the event
* @param event The event
*/
void onStateChanged(LifecycleOwner source, Lifecycle.Event event);
}
这个接口继承了LifecycleObserver接口，主要是用来将接收生命周期状态来调度我们的观察者的。接下来我们看下刚刚的Lifecycling.getCallback方法是如何实例GenericLifecycleObserver对象的
@NonNull
static GenericLifecycleObserver getCallback(Object object) {
if (object instanceof GenericLifecycleObserver) {
return (GenericLifecycleObserver) object;
}
//noinspection TryWithIdenticalCatches
try {
final Class<?> klass = object.getClass();
Constructor<? extends GenericLifecycleObserver> cachedConstructor = sCallbackCache.get(
klass);
if (cachedConstructor != null) {
return cachedConstructor.newInstance(object);
}
cachedConstructor = getGeneratedAdapterConstructor(klass);
if (cachedConstructor != null) {
if (!cachedConstructor.isAccessible()) {
cachedConstructor.setAccessible(true);
}
} else {
cachedConstructor = sREFLECTIVE;
}
sCallbackCache.put(klass, cachedConstructor);
return cachedConstructor.newInstance(object);
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
} catch (InstantiationException e) {
throw new RuntimeException(e);
} catch (InvocationTargetException e) {
throw new RuntimeException(e);
}
}
先整体看一下，这里是通过反射实例GenericLifecycleObserver对象的，并且这个目标类是的构造方法是有一个参数的，回顾上面调用这个方法时传递的参数，得知这个参数就是我们自己创建实现LifecycleObserver的类（用法中说到的ViewModel），接着看这个方法的实现，里面有一些缓存的处理和设置构造方法可以访问的处理应该都很好理解，主要看下14-21行的代码，其中调用了getGeneratedAdapterConstructor方法，来获取实现GenericLifecycleObserver接口类的构造方法
@Nullable
private static Constructor<? extends GenericLifecycleObserver> getGeneratedAdapterConstructor(
Class<?> klass) {
Package aPackage = klass.getPackage();
final String fullPackage = aPackage != null ? aPackage.getName() : "";
String name = klass.getCanonicalName();
// anonymous class bug:35073837
if (name == null) {
return null;
}
final String adapterName = getAdapterName(fullPackage.isEmpty() ? name :
name.substring(fullPackage.length() + 1));
try {
@SuppressWarnings("unchecked")
final Class<? extends GenericLifecycleObserver> aClass =
(Class<? extends GenericLifecycleObserver>) Class.forName(
fullPackage.isEmpty() ? adapterName : fullPackage + "." + adapterName);
return aClass.getDeclaredConstructor(klass);
} catch (ClassNotFoundException e) {
final Class<?> superclass = klass.getSuperclass();
if (superclass != null) {
return getGeneratedAdapterConstructor(superclass);
}
} catch (NoSuchMethodException e) {
// this should not happen
throw new RuntimeException(e);
}
return null;
}
static String getAdapterName(String className) {
return className.replace(".", "_") + "_LifecycleAdapter";
}
这个方法的作用是去递归查找你当前传递的观察者类（就是我们自定义实现LifecycleObserver接口的类，即上面的ViewModel类）所在包中是否存在名为观察者类名_LifecycleAdapter并且实现GenericLifecycleObserver接口的类的类（用ViewModel类说明也就是ViewModel_LifecycleAdapter），如果有那么就返回它的构造函数，否则继续查找递归查找你当前观察者类的父类的包中是否存在，如果都没有则方法null。
所以我们可以自己去监听一些事件来调度生命周期，注意如果要自己实现这个生命周期调度器，我们至少存在一个含义一个参数的构造函数，这个参数必须是我们自己创建的观察者类，用上面的例子也就是ViewModel类。当然一般情况下我们是不需要这样做的，如果我们没定义getGeneratedAdapterConstructor返回会返回null，然后getCallback方法中会判断是否为空，如果为空，那么就使用默认类的构造方法，也就是getCallback方法中的20行的处理，这里会给构造方法赋值sREFLECTIVE，下面我们看下这个sREFLECTIVE是什么
private static Constructor<? extends GenericLifecycleObserver> sREFLECTIVE;
static {
try {
sREFLECTIVE = ReflectiveGenericLifecycleObserver.class
.getDeclaredConstructor(Object.class);
} catch (NoSuchMethodException ignored) {
}
}
上面的代码不难看出，返回的是ReflectiveGenericLifecycleObserver类的构造方法，所以这个类就是为我们提供的默认调度器了，它接收一个Object对象，也就是说不关心我们观察者类具体是什么，现在重新回到调用Lifecycling.getCallback的地方，也就是ObserverWithState类中，记得这个类还有一个方法吧，也就是dispatchEvent方法，之前说过这个就是调度生命周期的方法，可以看到里面调用了我们刚刚实例的GenericLifecycleObserver对象的onStateChanged方法，ok，我们继续看一下系统默认提供的ReflectiveGenericLifecycleObserver类中对于onStateChanged方法的实现
@Override
public void onStateChanged(LifecycleOwner source, Event event) {
invokeCallbacks(mInfo, source, event);
}
private void invokeMethodsForEvent(List<MethodReference> handlers, LifecycleOwner source,
Event event) {
if (handlers != null) {
for (int i = handlers.size() - 1; i >= 0; i--) {
MethodReference reference = handlers.get(i);
invokeCallback(reference, source, event);
}
}
}
@SuppressWarnings("ConstantConditions")
private void invokeCallbacks(CallbackInfo info, LifecycleOwner source, Event event) {
invokeMethodsForEvent(info.mEventToHandlers.get(event), source, event);
invokeMethodsForEvent(info.mEventToHandlers.get(Event.ON_ANY), source, event);
}
private void invokeCallback(MethodReference reference, LifecycleOwner source, Event event) {
//noinspection TryWithIdenticalCatches
try {
switch (reference.mCallType) {
case CALL_TYPE_NO_ARG:
reference.mMethod.invoke(mWrapped);
break;
case CALL_TYPE_PROVIDER:
reference.mMethod.invoke(mWrapped, source);
break;
case CALL_TYPE_PROVIDER_WITH_EVENT:
reference.mMethod.invoke(mWrapped, source, event);
break;
}
} catch (InvocationTargetException e) {
throw new RuntimeException("Failed to call observer method", e.getCause());
} catch (IllegalAccessException e) {
throw new RuntimeException(e);
}
}
看上面ReflectiveGenericLifecycleObserver类中的部分代码，onStateChanged中调用了invokeCallbacks方法，invokeCallbacks中调用了两次invokeMethodsForEvent方法，一次是具体的事件，一次是固定的Event.ON_ANY事件，这里就印证了之前说的单独监听的方法会优先于监听ON_ANY事件的方法，然后我们继续看invokeMethodsForEvent方法这里循环调用了invokeCallback方法，也就是最终的触发监听生命周期回调的方法，这个方法中反射调用也就印证了之前我们在写监听方法时，可以为一个参数可以无参数，监听Event.ON_ANY时候是两个参数了，所以调用流程就是这样，但是你会问他们是如何得到这个方法的引用的呢，我们先回到invokeCallbacks中调用invokeMethodsForEvent方法时候传递的第一个参数info.mEventToHandlers.get(event)，所以成员变量info中保存着所有我们注册的方法，接下来回到构造方法中看下info的初始化
...
ReflectiveGenericLifecycleObserver(Object wrapped) {
mWrapped = wrapped;
mInfo = getInfo(mWrapped.getClass());
}
...
可以看到mInfo（onStateChanged中调用invokeCallbacks时候传递的是mInfo，所以invokeCallbacks中调用invokeMethodsForEvent中的info就是mInfo）是通过getInfo方法实例的，并且getInfo方法中传递了我们观察者类
private static CallbackInfo getInfo(Class klass) {
CallbackInfo existing = sInfoCache.get(klass);
if (existing != null) {
return existing;
}
existing = createInfo(klass);
return existing;
}
这个方法里面除了一些缓存处理，重点关注createInfo方法，这个才是最终实例的方法，同时也传递了之前传进来的类
private static CallbackInfo createInfo(Class klass) {
Class superclass = klass.getSuperclass();
Map<MethodReference, Event> handlerToEvent = new HashMap<>();
if (superclass != null) {
CallbackInfo superInfo = getInfo(superclass);
if (superInfo != null) {
handlerToEvent.putAll(superInfo.mHandlerToEvent);
}
}
Method[] methods = klass.getDeclaredMethods();
Class[] interfaces = klass.getInterfaces();
for (Class intrfc : interfaces) {
for (Entry<MethodReference, Event> entry : getInfo(intrfc).mHandlerToEvent.entrySet()) {
verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
}
}
for (Method method : methods) {
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
if (annotation == null) {
continue;
}
Class<?>[] params = method.getParameterTypes();
int callType = CALL_TYPE_NO_ARG;
if (params.length > 0) {
callType = CALL_TYPE_PROVIDER;
if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
throw new IllegalArgumentException(
"invalid parameter type. Must be one and instanceof LifecycleOwner");
}
}
Event event = annotation.value();
if (params.length > 1) {
callType = CALL_TYPE_PROVIDER_WITH_EVENT;
if (!params[1].isAssignableFrom(Event.class)) {
throw new IllegalArgumentException(
"invalid parameter type. second arg must be an event");
}
if (event != Event.ON_ANY) {
throw new IllegalArgumentException(
"Second arg is supported only for ON_ANY value");
}
}
if (params.length > 2) {
throw new IllegalArgumentException("cannot have more than 2 params");
}
MethodReference methodReference = new MethodReference(callType, method);
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
}
CallbackInfo info = new CallbackInfo(handlerToEvent);
sInfoCache.put(klass, info);
return info;
}
先整体看下createInfo方法，其实主要就是验证和反射查找我们的观察者类中的使用OnLifecycleEvent注解注释的方法，所以这时理解为什么我们在监听生命周期时需要使用这个注解了吧，这里的代码也非常简单就不细说了，不明白的朋友可以查一下反射相关的知识。
所以现在就很清晰了，最开始Lifecycle的子类LifecycleRegistry调用addObserver方法中创建了ObserverWithState对象，然后通过ObserverWithState中的dispatchEvent方法调度事件，传递给GenericLifecycleObserver的实现类默认的ReflectiveGenericLifecycleObserver或者自己实现的xxx_LifecycleAdapter类，从而调度生命周期，所以现在我们只需要知道ObserverWithState的dispatchEvent方法是什么时候调用的既可。
主要就是LifecycleRegistry中的forwardPass和backwardPass方法，而这两方法是在sync方法中判断调用的，而sync方法是通过handleLifecycleEvent方法触发的，我们先不管为什么需要判断从而触发forwardPass或backwardPass，先说一下handleLifecycleEvent方法的调用，他是在一个叫做ReportFragment的Fragment类中调用的，我们先来说下这个ReportFragment的作用。
这个类是用来监听生命周期的，这个类里面有一个injectIfNeededIn方法
public static void injectIfNeededIn(Activity activity) {
// ProcessLifecycleOwner should always correctly work and some activities may not extend
// FragmentActivity from support lib, so we use framework fragments for activities
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null) {
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
// Hopefully, we are the first to make a transaction.
manager.executePendingTransactions();
}
这个方法是在Support包中SupportActivity的onCreate方法中调用的，所以这样就关联上了Activity的生命周期，所以在ReportFragment中的生命周期方法中触发触发dispatch方法从而触发了LifecycleRegistry的handleLifecycleEvent方法
private void dispatch(Lifecycle.Event event) {
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) {
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
}
if (activity instanceof LifecycleOwner) {
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry) {
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
}
}
}
因为继承的Support包中的Activity中实现了LifecycleOwner接口，而这个返回的是LifecycleRegistry（上面说过）所以就可以调用LifecycleRegistry的handleLifecycleEvent方法了。现在我们就理解了，为什么我们继承Support包中的Activity就可以使用Lifecycle组件了吧。当然你会问如果我们继承Fragment时候呢，什么时候触发的handleLifecycleEvent方法呢，其实很简单就是在Fragment中的比如performStart，performResume等方法中直接调用的，这里就不做过多解释了，可以具体看下Support中Fragment的代码。
接下来回到刚刚没有说明LifecycleRegistry中的forwardPass和backwardPass方法，为什么会有两个方法来触发生命周期事件，还记得我在介绍如何使用Lifecycle组件时最后说的么，生命周期事件是根据Lifecycle中的状态触发的，Lifecycle的状态如下
public enum State {
/**
* Destroyed state for a LifecycleOwner. After this event, this Lifecycle will not dispatch
* any more events. For instance, for an {@link android.app.Activity}, this state is reached
* <b>right before</b> Activity's {@link android.app.Activity#onDestroy() onDestroy} call.
*/
DESTROYED,
/**
* Initialized state for a LifecycleOwner. For an {@link android.app.Activity}, this is
* the state when it is constructed but has not received
* {@link android.app.Activity#onCreate(android.os.Bundle) onCreate} yet.
*/
INITIALIZED,
/**
* Created state for a LifecycleOwner. For an {@link android.app.Activity}, this state
* is reached in two cases:
* <ul>
* <li>after {@link android.app.Activity#onCreate(android.os.Bundle) onCreate} call;
* <li><b>right before</b> {@link android.app.Activity#onStop() onStop} call.
* </ul>
*/
CREATED,
/**
* Started state for a LifecycleOwner. For an {@link android.app.Activity}, this state
* is reached in two cases:
* <ul>
* <li>after {@link android.app.Activity#onStart() onStart} call;
* <li><b>right before</b> {@link android.app.Activity#onPause() onPause} call.
* </ul>
*/
STARTED,
/**
* Resumed state for a LifecycleOwner. For an {@link android.app.Activity}, this state
* is reached after {@link android.app.Activity#onResume() onResume} is called.
*/
RESUMED;
/**
* Compares if this State is greater or equal to the given {@code state}.
*
* @param state State to compare with
* @return true if this State is greater or equal to the given {@code state}
*/
public boolean isAtLeast(State state) {
return compareTo(state) >= 0;
}
}
可以看到只有这5种状态，那么它是怎么判断触发生命周期的呢，点击这里官网中有一个图很清晰的介绍了它的判断，我在这里简单说明一下
当state从INITIALIZED或者DESTROYED到CREATED时触发ON_CREATE事件，然后从CREATED到STARTED时触发ON_START事件，然后从STARTED到RESUMED触发ON_RESUME事件。
然后从RESUMED到STARTED时触发ON_PAUSE事件，从STARTED到CREATED时触发ON_STOP事件，接着从CREATED到DESTROYED触发ON_DESTROY事件。
可以看出状态可以由上至下，也可以由下至上，所以现在理解了LifecycleRegistry中为什么有两个方法forwardPass和backwardPass来调度事件了吧。
也写了不少了，就告一段落吧，希望对开始使用Lifecycle组件的你带来帮助。